Re: Testing virtual hosts on a virtual machine
am 24.11.2009 18:53:51 von Tom Evans
--0015174015c0f5cc180479219f52
Content-Type: text/plain; charset=UTF-8
On Tue, Nov 24, 2009 at 5:39 PM, Florent Georges wrote:
> Hi,
>
> I am using a virtual box (Ubuntu server 9.10 with VMware Fusion)
> to test a web server. No problem to install Apache on this
> Ubuntu box, of course. And I can access the default page after
> an install by using http://xxx.xxx.xx.xx/ in my browser (on the
> host machine.)
>
> But the web server will use named virtual hosts. I guess that
> won't work as the browser won't send the correct domain name.
>
> Is there any tool to test an Apache instance with virtual hosts
> on a virtual machine? Any best practice or advice to follow in
> that configuration?
>
> Regards,
>
>
I've used a couple of different ways, depending on how magic/special you
like it. I'll outline them in terms of difficulty :)
1) Add your testing hostname to /etc/hosts:
Eg, if you want to test www.foocorp.com, and your vm's IP address is
10.0.1.10, then put this in /etc/hosts
10.0.1.10 www.foocorp.com
In windows, this is \system32\drivers\etc\hosts or somewhere along
those lines.
Once you do this, you can't go to the real www.foocorp.com without removing
the /etc/hosts entry
2) Run squid on the VM
Squid can do almost anything with HTTP, and works quite well at this. Once
you have squid configured as a regular cache, you add this kind of
configuration:
acl tested_sites dstdomain www.foocorp.com
cache_peer my-regular-upstream-cache parent 3128 0 proxy-only default
cache_peer the-ip-of-the-vhost-apache parent 80 0
cache_peer_access my-regular-upstream-cache deny tested_sites
cache_peer_access the-ip-of-the-vhost-apache deny !tested_sites
never_direct allow all
Basically, this configuration says to send anything not in the tested_sites
ACL to the regular upstream cache, whilst sending anything in tested_sites
to the apache server. Apache and squid are robust enough to do this without
any other changes. If you don't have an upstream squid, then the
configuration would need to be different - I'm no squid expert, so check the
manuals/squid mailing list if you want to do this.
Once you have squid set up and running, you can configure your browser to
switch between using this proxy, and using your regular upstream proxy/no
proxy. I use the firefox plugin SwitchProxy, two clicks to switch to my
testing infrastructure.
The advantage of the squid approach is that the hacks are all centralized on
one box, with no changes required on client machines, making it easier to
allow access to your test infrastructure.
Cheers
Tom
--0015174015c0f5cc180479219f52
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Tue, Nov 24, 2009 at 5:39 PM, Florent Georges=
<darkman_spa=
m@yahoo.fr> wrote:
=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; p=
adding-left: 1ex;">
 Hi,
 I am using a virtual box (Ubuntu server 9.10 with VMware Fusion)
to test a web server. Â No problem to install Apache on this
Ubuntu box, of course. Â And I can access the default page after
an install by using
htt=
p://xxx.xxx.xx.xx/ in my browser (on the
host machine.)
 But the web server will use named virtual hosts.  I guess that<=
br>
won't work as the browser won't send the correct domain name.
 Is there any tool to test an Apache instance with virtual hosts
on a virtual machine? Â Any best practice or advice to follow in
that configuration?
 Regards,
I've used a couple of different ways, depending =
on how magic/special you like it. I'll outline them in terms of difficu=
lty :)
1) Add your testing hostname to /etc/hosts:
Eg, if you=
want to test , and y=
our vm's IP address is 10.0.1.10, then put this in /etc/hosts
10.0.1.10
>In windows, this is <WINDOWS>\system32\drivers\etc\hosts or somewher=
e along those lines.
Once you do this, you can't go to the real =
without removing the=
/etc/hosts entry
2) Run squid on the VM
Squid can do almost anything with HTTP, a=
nd works quite well at this. Once you have squid configured as a regular ca=
che, you add this kind of configuration:
acl tested_sites dstdomain =
cache_peer my-regular-upstream-cache parent 3128 0 proxy-only default
ca=
che_peer the-ip-of-the-vhost-apache parent 80 0
cache_peer_access my-reg=
ular-upstream-cache deny tested_sites
cache_peer_access the-ip-of-the-vh=
ost-apache deny !tested_sites
never_direct allow all
Basically, this configuration says to send an=
ything not in the tested_sites ACL to the regular upstream cache, whilst se=
nding anything in tested_sites to the apache server. Apache and squid are r=
obust enough to do this without any other changes. If you don't have an=
upstream squid, then the configuration would need to be different - I'=
m no squid expert, so check the manuals/squid mailing list if you want to d=
o this.
Once you have squid set up and running, you can configure your browser =
to switch between using this proxy, and using your regular upstream proxy/n=
o proxy. I use the firefox plugin SwitchProxy, two clicks to switch to my t=
esting infrastructure.
The advantage of the squid approach is that the hacks are all centraliz=
ed on one box, with no changes required on client machines, making it easie=
r to allow access to your test infrastructure.
Cheers
Tom
--0015174015c0f5cc180479219f52--
RE: Testing virtual hosts on a virtual machine
am 24.11.2009 19:55:35 von James Zuelow
> -----Original Message-----
> From: Emmanuel Bailleul [mailto:Emmanuel.Bailleul@telindus.fr]=20
> Sent: Tuesday, 24 November, 2009 09:49
> To: users@httpd.apache.org
> Subject: RE: [users@httpd] Testing virtual hosts on a virtual machine
>=20
>=20
> > -----Message d'origine-----
> > De=A0: Florent Georges [mailto:darkman_spam@yahoo.fr]
> > Envoyé : mardi 24 novembre 2009 18:39
> > À : Apache HTTPD users list
> > Objet=A0: [users@httpd] Testing virtual hosts on a virtual machine
> >=20
> > Hi,
> >=20
> > I am using a virtual box (Ubuntu server 9.10 with VMware Fusion)
> > to test a web server. No problem to install Apache on this
> > Ubuntu box, of course. And I can access the default page after
> > an install by using http://xxx.xxx.xx.xx/ in my browser (on the
> > host machine.)
> >=20
> > But the web server will use named virtual hosts. I guess that
> > won't work as the browser won't send the correct domain name.
> >=20
> > Is there any tool to test an Apache instance with virtual hosts
> > on a virtual machine? Any best practice or advice to follow in
> > that configuration?
> >=20
> > Regards,
> >=20
> > --
> > Florent Georges
>=20
> Hi,
>=20
> Why not just use curl with '-H' option, just as in:
> $ curl -v -H "Host: vh1.domain.tld" http://
>=20
> This way curl will request httpd using "Host: vh1.domain.tld" header.
>=20
> Regards.
>=20
> Emmanuel
>=20
You could also adjust the hosts file on a machine you use for testing, so t=
hat the virtual host names all point to the IP address of the virtual machi=
ne. That would allow you to use normal browsers, etc.
James=
------------------------------------------------------------ ---------
The official User-To-User support forum of the Apache HTTP Server Project.
See for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: Testing virtual hosts on a virtual machine
am 24.11.2009 21:21:30 von aw
Florent Georges wrote:
> Hi,
>
> I am using a virtual box (Ubuntu server 9.10 with VMware Fusion)
> to test a web server. No problem to install Apache on this
> Ubuntu box, of course. And I can access the default page after
> an install by using http://xxx.xxx.xx.xx/ in my browser (on the
> host machine.)
>
> But the web server will use named virtual hosts. I guess that
> won't work as the browser won't send the correct domain name.
>
> Is there any tool to test an Apache instance with virtual hosts
> on a virtual machine? Any best practice or advice to follow in
> that configuration?
>
Because the information available when searching for this on Google or
on Wikipedia, and even on the Apache website is rather confusing, let me
try to give you an explanation of how this stuff really works.
It is a bit long, but I believe that if you understand the explanation
below, you will never have trouble again with Virtual Hosts.
And also a lot less trouble with browsers and http in general.
Still with me ?
When you ask a browser to access "http://myhost.company.com", what
really happens ?
1) the browser asks the local operating system to "translate" the name
"myhost.company.com" into an IP address.
The operating system, to do that, works in 2 steps :
1.1) the OS looks into the local "hosts" file, to see if it finds a line
like
aaa.bbbb.ccc.ddd myhost.company.com
If it does, then it returns the IP address "aaa.bbbb.ccc.ddd" to the
browser, as a translation for the name "myhost.company.com", and it is
finished.
1.2) if the above did not work, then the OS will ask, over the network,
to a DNS server to do the same translation. The DNS server will look up
its own tables, and in the end it can either answer with an IP address,
or with "not found".
The OS will then pass back this same answer to the browser, and it is
finished.
(Of course, this supposes that the OS has a working DNS server to talk
to, otherwise it will return an error to the browser right away).
2) Now the browser has an answer, which is either a "host not found", or
an IP address.
2.1) If it was a "host not found", the browser tells the user and that's it.
2.2) If the browser has received an IP address however, then the process
continues.
3) the browser establishes a TCP/IP connection with the received IP
address, on port 80.
That either works, or doesn't.
3.1) If it doesn't work, the browser sends an error message to the user
: cannot connect to "myhost.company.com", and again that's it.
(It may fail to work, for example because there is no host at that IP
address, or because there is a host, but there is no program there
listening to connections on port 80; or for many other reasons).
3.2) If it works, the process continues.
(That it works, implies that on the target server there is a process
which actually listens to connection requests on port 80, and accepts
them. That will generally be a webserver like Apache).
4) the browser, over this now established TCP connection to the server
at that IP address:port 80, sends a HTTP request to that server. This
HTTP request consists of minimum 2 lines of text, as follows :
GET / HTTP/1.1
Host: myhost.company.com
The first line indicates, in the middle, what resource the browser
wants. In this case, it just wants the default home page, so the
resource URL is "/".
The second line indicates which "virtual host" the browser wants to talk
to, on the target server (with whom it already has a TCP connection).
After sending that request, the browser starts waiting for a server
answer over that same TCP connection.
5) the receiving Apache HTTP server receives the above request, and
looks at the "Host:" line.
Now the receiving Apache HTTP server is going to try to "match" this
hostname, with the name of one of the VirtualHost's that are defined in
its configuration. It either finds a match, or it does not.
5.1) if it does find a match, then it will process this request using
the "personality" of the VirtualHost that is defined for that name.
5.2) if it does not find a match, then it will process this request
using the personality of the first defined VirtualHost, from top to
bottom of the configuration file. (It does not matter in that case if
the hostname matches or not, it will use this first VirtualHost as the
"default host".)
To give you a practical example :
Suppose you have a server with an IP address of 192.168.100.100.
On that server, you install Apache.
In Apache, you define a new (additional) , and you give it
the configuration lines
ServerName www.google.com # (really, for the example)
DocumentRoot /var/www/some-new-dir
DirectoryIndex index.html
In that new directory /var/www/some-new-dir, place a html page named
"index.html", containing a "Hello, I'm Google !" message.
And you restart Apache.
Then, on your local workstation, edit the "hosts" file (under Windows,
this is at c:/windows/system32/drivers/etc/hosts; under Unix/Linux, it
is at /etc/hosts).
Add the following line to it :
192.168.100.100 www.google.com # (really, for the example)
(change the IP address to the real IP of the host running Apache)
Then on your local workstation, call up the browser, and enter the URL
"http://www.google.com".
What happens, is what I described above, in the following sequence :
1), 1.1), 2), 2.2), 3), 3.2), 4), 5), 5.1)
Now go back to edit the local hosts file, and comment out the line that
you added before.
Close the browser, re-open it, and ask again for "http://www.google.com".
Obviously, you do not get the same page. Why ?
Because this time, what happened is
1), 1.1), 1.2), 2), 2.2), 3), 3.2), 4), 5), 5.1)
small difference, big effect.
In all the above, there are 2 essential elements :
- the local browser must know which IP address corresponds to the name
of the virtual host
- the Apache server must know that it has a virtual server with that name
It does not matter whether the Apache host is a physical machine or a
virtual machine. As long as your IP networking setup, and the hostname
resolving mechanism (known as "the resolver") are working, it will work.
There are no "tricks" involved. It is pure logic at every step.
------------------------------------------------------------ ---------
The official User-To-User support forum of the Apache HTTP Server Project.
See for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org